\documentclass[a4paper,12pt,oneside]{article} % définition des différents parametres. Le dernier peut-être de type report ou article (modifie le chapitrage)
\usepackage[francais]{babel} %déclaration de la langue du document
\usepackage[utf8x]{inputenc} %déclaration du jeu de caractéres à utiliser
%\usepackage[top=2.5cm, bottom=2.5cm, left=2.5cm, right=2.5cm]{geometry} %permet de modifier les marges
\usepackage[pdftex]{graphicx} %package nécessaire pour l'insertion d'images
\usepackage{graphics} %package nécessaire pour l'insertion d'images
\usepackage{wrapfig} %package nécessaire pour l'insertion d'images
\usepackage{array} % meilleur gestion des tableaux
\usepackage{xcolor}
\usepackage{shorttoc}
\usepackage{pdfpages}
\usepackage{glossary}
\usepackage{array}
\usepackage{caption}
\usepackage{float}
\usepackage{vmargin}
\usepackage{listings}

\makeglossary

\newcommand{\cita}[2]{\footnote{\cite[#1]{#2}, cf page \pageref{bib}.}}

\newcommand{\HRule}{\rule{\linewidth}{0.5mm}}

\title{Design Pattern } %titre du document
\author{Michael GRANDIN} %auteurs du document

\begin{document}
\begin{titlepage}
\begin{center}
% Partie supérieure de la page
\includegraphics[width=0.28\textwidth]{iutbm.jpg}\\[0.5cm]

\textsc{\Large IUT de Belfort-Montbéliard}\\[1.0cm]

% Titre
\HRule \\[0.4cm]
{ \huge \bfseries Design Pattern}\\[0.4cm]

\HRule \\[0.4cm]


%Auteur 
\begin{minipage}{0.5\textwidth}
\begin{flushleft} \large
\textit{Auteurs}

Michael \textsc{Grandin}

\end{flushleft}
\end{minipage}
\begin{minipage}{0.4\textwidth}
\begin{flushright} \large

\textcolor{white}{blabla}\\
\end{flushright}
\end{minipage}

\vfill

% bas de page
{\large Année Universitaire 2009-2010}

\end{center}

\end{titlepage}

%\sommaire %insertion du sommaire crée grâce à shorttoc
\newpage

\section{Introduction}
Un design pattern ou "patron de conception" en Français est un concept de génie logiciel destiné à résoudre les problèmes récurrents en suivant les principes de la Programmation Orienté Objet(POO). Ils s'apparentent à des algorithmes et sont donc indépdendant de tout langage de programmation. Il en existe de nombreux, mais nous allons nous interresser dans notre cas au Design Pattern Visiteur(visitor) dans le langage JAVA.

\section{Définition}
Le but du Design Pattern Visiteur est de reussir à séparer l'algorithme de la structure de l'objet sur lequel il opère. Après cette opération il est possible alors de faire de nouvelles opérations sur la structure existante de l'objet sans pour autant modifier cette structure. Ainsi le Design Pattern visitor aide à la conformité avec le principe dit d'ouverture/fermeture d'une classe qui dit que cette classe doit être à la fois ouvert et fermé. Ouverte pour pouvoir être étendue, et fermé qui veut dire qu'elle ne peut être modifié que par extansion. 
Le visiteur peut ajouter de nouvelles fonction "virtuelles" dans les classes sans modifiers les classes elles-mêmes.
Le design pattern visiteur est très souvent utilisé lorsque l'on veut traiter des collections avec à l'intérieur un tas d'objet de type différent. Les traitements sur chaque objet ne seront pas les même, il convient donc de les différencier. La solution la plus évidente est donc de vérifier le type avec une structure de type "if" "else" mais cela peut devenir très compliqué et fastidieux.
C'est la que le design patern intervient.


\section{Fonctionnement du design pattern}
La première chose à faire est de créer une interface pour le visiteur qui contiendra tout les éléments qu'il aura la possibilité de visiter. Ensuite on crée une deuxième interface qui sera instauré dans chaque objets qui seront visité. La visite s'effectue ensuite assez simplement, il suffit d'appeler la méthode "accept" de l'objet en lui donnant une instance de visiteur. 

\section{Exemple}

Pour illustrer ce design pattern, rien de mieux qu'un exemple.
On se place dans le cadre d'une visite d'une maison. Celle-ci comporte une multitude d'objets, comme une cuisine, une chambre, un garage, des meubles ...
Le but vas tout simplement de les visiter et d'y implementer quelque methodes.

\definecolor{colKeys}{rgb}{0,0,1}
\definecolor{colIdentifier}{rgb}{0,0,0}
\definecolor{colComments}{rgb}{0,0.5,1}
\definecolor{colString}{rgb}{0.6,0.1,0.1}

\lstset{
basicstyle=\ttfamily\small, %
identifierstyle=\color{colIdentifier}, %
keywordstyle=\color{colKeys}, %
stringstyle=\color{colString}, %
commentstyle=\color{colComments}
}
\lstset{language=java}

\begin{itemize}
    \item Pour commencer voici l'interface du visiteur, il contient les prototypes des méthodes que l'on va devoir implementer pour chaque objet visité. Ceci afin de forcer le programmeur à implementer toutes les méthodes.
\end{itemize}
\begin{lstlisting}
interface VisiteurMaison {                      
    void visite(Cuisine cuisine);
    void visite(Chambre chambre);
    void visite(Maison maison);
    void visite(Armoire armoire);
    void visite(Garage garage);
    void visite(Voiture voiture);
}
\end{lstlisting}
\begin{itemize}
	\item L'interface précédente donne la classe Visiteur suivante. On affiche une petite phrase pour chaque élément visité. \\
On peut également y appeler les méthodes de l'objet visité ! 
\end{itemize}

\begin{lstlisting}
class Visiteur implements VisiteurMaison {
    public void visite(Maison maison){
        System.out.println(maison);
    }
    public void visite(Cuisine cuisine){      
        System.out.println("Visite de la cuisine "+ cuisine.getTaille() + " m^2");
	}

	...

\end{lstlisting}

\begin{itemize}
    \item Ici l'interface qui sera implementer par toutes les objets qui voudront être visités.
\end{itemize}
\begin{lstlisting}
interface ElementDeMaison {                              
    void accept(VisiteurMaison visitor);                 
}
\end{lstlisting}

\begin{itemize}
    \item Exemple d'une l'implementation d'un objet avec l'interface ElementDeMaison.
\end{itemize}
\begin{lstlisting}
class Cuisine implements ElementDeMaison{                 
    private int taille ;
    public Cuisine(int taille) {
        this.taille = taille;
    }    
    public void accept(VisiteurMaison visitor) {
        visitor.visite(this);
    }
}
\end{lstlisting}


\begin{itemize}
	\item On fait de même avec les classe restantes que l'on veut visiter. 
	Pour visiter la maison, rien de plus simple. On appel la méthode accept de la classe Maison en lui donnant une instance de visiteur pouvant être anonyme.
\end{itemize}

\begin{lstlisting}
public class VisiteurDem {
	...
	maison.accept(new VisiteurElementDeMaison());
	...
}
\end{lstlisting}

\begin{itemize}
	‪\item Cette méthode va visiter la maison et appeler les méthodes "visit" des éléments qu'elle contient afin de les mettre dans le visiteur.
\end{itemize}
\begin{lstlisting}
    public void accept(VisiteurMaison visitor) {	        
        for(ElementDeMaison element : this.getElements()){
            element.accept(visitor);
        }
        visitor.visite(this);	
    }
\end{lstlisting}

\begin{itemize}
	\item et le resultat est le suivant.
\end{itemize}

\begin{lstlisting}
	Visite de la cuisine 20 m^2
	Visite du garage 30 m^2
	Visite d une armoire intitule Commode
	Nombre de cases de cette armoire : 10
	Visite d une armoire intitule etagere
	Nombre de cases de cette armoire : 15
	Visite de la voiture qui est de la marque Peugeot 206
	Visite de la chambre qui fait 50 m^2

	La maison possede en tout: 
 		- une cuisine 
 		- un garage 
 		- deux armoires 
 		- une voiture 
 		- une chambre

\end{lstlisting}


\section{Avantage/Inconvenient}
    Ce design pattern semble très interessant dans le sens ou il aide le programmeur à mieux structurer son code, lui évitant de mettre des longues series de if/else ou de switch. Il permet en effet d'acceder facilement aux attributs des l'objet visité. 

	Mais il a l'inconvénient d'être assez gourmand en ressource.


\section{conclusion}
    Bien que puissant, le modèle de visiteur est plus limité que les fonctions classiques virtuelles. Il n'est pas possible de créer des visiteurs pour les objets sans y ajouter une méthode de rappel à l'intérieur de chaques classes.Dans les implémentations dite "naïve", la méthode de rappel dans chacune des classes n'est pas héréditaire.

\end{document}
